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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration 
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by 
functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service (QOS). The CM actions are 
initiated either as single actions on single NEs of the 3G network, or as part of a complex procedure involving actions 
on many resources/objects in one or several NEs. 

Due to the growing number of specifications to model new services and Resource Models for Configuration 
Management (CM), as well as the expected growth in size of each of them from 3GPP Release 4 onwards, a new 
structure of the specifications is already needed in Release 4. This structure is needed for several reasons, but mainly to 
enable more independent development and release for each part, as well as a simpler document identification and 
version handling. Another benefit would be that it becomes easier for bodies outside 3GPP, such as the ITU-T, to refer 
to telecom management specifications from 3GPP. The new structure of the specifications does not lose any 
information or functionality supported by the Release 1999. The restructuring also includes defining new IRPs for the 
Network Resource Models (Generic, Core Network and UTRAN NRM). 

Finally, the Name convention for Managed Objects (in Release 1999: 32.106-8) has been moved to a separate number 
series used for specifications common between several management areas (e.g. CM, FM, PM). 

The following table shows an overview of the mapping between the old Release 1999 and new Release 4 CM 
specification structure. 
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Table: Mapping between Release '99 and the new Rel-4 specifications 



R99 
Old no. 


Old (R99) specification title 


Rel-4 
New no. 


New (Rel-4) specification title 


32.106-1 


3G Configuration Management: Concept and Requirements 


32.600 


3G Configuration Management: Concept and 
High-level Requirements 


32.106-1 


<Notification IRP requirements from 32.106-1 and 32.106-2> 


32.301 


Notification IRP: Requirements 


32.106-2 


Notification IRP: IS 


32.302 


Notification IRP: Information Service 


32.106-3 


Notification IRP: CORBA SS 


32.303 


Notification IRP: CORBA SS 


32.106-4 


Notification IRP: CMIP SS 


32.304 


Notification IRP: CMIP SS 


32.106-8 


Name convention for Managed Objects 


32.300 


Name Convention for Managed Objects 


32.106-1 


<Basic CM IRP IS requirements from 32.106-1 and 32.106-5> 


32.601 


Basic CM IRP: Requirements 


32.106-5 


Basic CM IRP IM (Intro & IS part) 


32.602 


Basic CM IRP: Information Service 


32.106-6 


Basic CM IRP CORBA SS (IS related part) 


32.603 


Basic CM IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (IS related part) 


32.604 


Basic CM IRP: CMIP SS 


32.106-1 


<Basic CM IRP Generic NRM requirements from 32.106-1 and 
32.106-5> 


32.621 


Generic Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (Generic NRM part) 


32.622 


Generic Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (Generic NRM related part) 


32.623 


Generic Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (Generic NRM related part) 


32.624 


Generic Network Resources IRP: CMIP SS 


32.106-1 


<Basic CM IRP CN NRM requirements from 32.106-1 and 32.106- 

5> 


32.631 


Core Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (CN NRM part) 


32.632 


Core Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (CN NRM related part) 


32.633 


Core Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (CN NRM related part) 


32.634 


Core Network Resources IRP: CMIP SS 


32.106-1 


<Basic CM IRP UTRAN NRM requirements from 32.106-1 and 
32.106-5> 


32.641 


UTRAN Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (UTRAN NRM part) 


32.642 


UTRAN Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (UTRAN NRM related part) 


32.643 


UTRAN Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (UTRAN NRM related part) 


32.644 


UTRAN Network Resources IRP: CMIP SS 
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Scope 



The present document defines a component of an Integration Reference Point (IRP) through which an IRP Agent' 
(typically an Element Manager or Network Element) can communicate basic Configuration Management related 
information to one or several IRPManagers' (typically Network Managers). 

This version of the IRP is mainly intended for "passive management" of high-level network configuration and status 
information as required by a Network Manager. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs - as described in the Introduction clause above. An important aspect of such a split is that the 
Network Resource Models (NRMs) defined in different IRPs containing NRMs are consistent, and that NRMs 
supported by an IRP Agent implementation can be accessed as one coherent model through one IRP Information 
Service. The Basic CM IRP: IS defined herein provides one such Information Service. 

Thus, to summarize, the Basic CM IRP: IS defined in the present document has the following main purpose: to define 
an interface for retrieval of Configuration Management information. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[4] 3GPP TS 32.312: "Telecommunication management; Generic Integration Reference Point (IRP) 

management; Information Service (IS)". 

Void. 

ITU-T Recommendation X.710 (1991): "Common Management Information Service Definition 
for CCITT Applications". 

ITU-T Recommendation X.721 (02/92): "Information Technology - Open Systems Interconnection 

- Structure of Management Information: Definition of Management Information". 

ITU-T Recommendation X.730 (01/92): "Information Technology - Open Systems Interconnection 

- Systems Management: Object Management Function". 

ITU-T Recommendation X.733 (02/92): "Information Technology - Open Systems Interconnection 
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convention for Managed Objects". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.600 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently however, all (non-containment) associations are modelled by means of reference 
attributes of the participating MOs. 

Managed Element (ME): An instance of the Managed Object Class G3ManagedElement. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the objects 
that belong to the class. Furthermore, an MO class can have operations that represent the behaviour relevant for that 
class. An MO class may support notifications that provide information about an event occurrence within a network 
resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 



(3) 



a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 3.1 depicts the relationships 
between a Name space and a number of participating MOs (the shown association is of a non-containment 
type) 




^Namespace (containment hierarhy) 
O MO y MIB 
Association 

Figure 3.1 : Relationships between a Name space and a number of participating MOs 

Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.300 [13]) restricts the 
name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
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MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the lub interface towards the RNC. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DN Distinguished Name (see 3GPP TS 32.300 [13]) 

EM Element Manager 

FM Fault Management 

IDL Interface Definition Language 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MO Managed Object 

MOC Managed Object Class 

MOI Managed Object Instance 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.300 [13]) 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 
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4 System overview 

4.1 System context 

Figure 4.1 and figure 4.2 identify system contexts of the subject IRP in terms of its implementation called IRP Agent 
and the user of the IRP Agent, called IRPManager. For a definition of IRPManager and IRP Agent, see 3GPP 

TS 32.102 [2]. 

The IRP Agent implements and supports the Basic CM IRP: IS. The IRP Agent can be an Element Manager (EM) or a 
mediator that interfaces one or more NEs (see Figure 4. 1), or it can be a Network Element (NE) (see Figure 4.2). In the 
former case, the interfaces (represented by a thick dotted line) between the EM and the NEs are not subject of this IRP. 

An NE can be managed via System Context A or B. The criterion for choosing System Context A or B to manage a 
particular NE is implementation dependent. An IRP Agent shall support one of the two System Contexts. By observing 
the interaction across the Itf-N, an IRPManager cannot deduce if the IRP Agent supports System Context A or B. 









1 
1 


















IRPManager 






IRPAgent 






1 

1 






NM 








EM 





NEs 



Itf-N 



Notification IRP 
Basic CM IRP 



Figure 4.1 : System Context A 



IRPManager 



NM 



1 



IRPAgent 



NE 




1 



Notification IRP 
Basic CM IRP 



Figure 4.2: System Context B 



4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2]. 

An IRPAgent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 



Given that 



rules for vendor-specific extensions remain to be fully specified, and 
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• many scenarios under which IRPManager and IRP Agent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor- specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 



5 Modelling approach 

This clause identifies the modelling approach adopted and used in this IRP. 

As described in 3GPP TS 32.101 [1], an IRP comprises the following components: 

(1) an IRP Information Model that specifies the interface in a protocol neutral manner, defined as an Information 
Service and/or one or more Network Resource Models, 

(2) a number of IRP Solution Sets that provide the actual realization of the operations and notifications defined in 
the IRP Information Model for each protocol environment. 

The present document defines one such Information Service - the Basic CM IRP: IS. 

The IRP Information Service is a specification of the operations and notifications that are visible over the IRP. These 
operations/notifications are generic in the sense that they do not specify the Managed Objects that are 
retrieved/manipulated/informed about over the interface, and thus this IS is independent of the NRM being managed. 

5.1 IRP Information Service modelling approach 

The IRP Information Service of the subject IRP specifies a number of protocol-independent operations and notifications 
that are needed by an IRPManager to retrieve CM information from an IRP Agent. 

The operations and notifications of the IRP Information Service are mainly based on the principles of the Common 
Management Information Service (CMIS) defined in ITU-T Recommendation X.710 [7] and ITU-T Recommendation 
X.721 [8] (M-GET etc.). Note however, that the Information Service of the subject IRP is focused on the operations and 
notifications needed for basic CM purposes and thus only covers a subset of the operations/notifications defined in 
ITU-T Recommendation X.710 [7]/ITU-T Recommendation X.721 [8]. 

It is expected that most Solution Sets will implement the operations and notifications by mapping them to standard 
operations (and possibly standard notifications) that are applicable in the corresponding protocol environment. 
A CMIP Solution Set should for instance map the operations to the more generic operations defined in CMIS, an SNMP 
Solution Set should map the operations to applicable SNMP operations, and a CORBA Solution Set should map the 
operations to applicable OMG/CORBA services. 
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IRP Information Service 



This clause specifies the operations and notifications that are visible over this IRP. These operations are generic in the 
sense that they do not specify the MOs that are retrieved/manipulated over the interface. 



6.1 



Interfaces 



Figure 6.1 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager, described using UML notation (Interface in IRP Information Model is identical to concepts conveyed by 
stereotype «interface» of UML). Parameters and return status are not indicated. 

Two interfaces are defined. One is called BasicCmlRPOperations. This interface defines operations implemented 
by IRPAgent and used (or called) by IRPManager. The other is called BasicCmlRPNotif ications. This interface 
defines notifications implemented by IRPManager and used by IRPAgent. 



<<lnterface>> 
BasicCmlRPOperations 




^getlVlo Attributes 

^etContainmentO 

%getBasicCmlRPVersion() 
^cancelOperationO 




<<lnterface>> 
BasicCmlRPNotifications 



|inotifyObjectCreation() 
l^notifyObjectDeletionO 
%notifyAttributeValueCliange() 



Figure 6.1 : UML Interface Class Diagram 
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6.2 Operations 

6.2.1 Operation getMoAttributes (IVI) 

This operation is invoked by IRPManager to request the retrieval of management information (Managed Object 

attribute names and values) from the MIB maintained by IRP Agent. One or several Managed Objects may be retrieved - 

based on the containment hierarchy. The operation corresponds to the M-GET service defined by CMIS (ITU-T 

Recommendation X.7 10 [7]). 

A Solution Set may choose to split this operation in several operations (e.g. operations to get "handlers" or "iterators" to 

Managed Objects fulfilling the scope/filter criteria and other operations to retrieve attribute names/values from these 

"handlers"). 

Table 1 : Parameters of getMoAttributes 



Name 


Qualifier 


Description 


invokeldentifierin 


Input, C 


This parameter identifies the current invocation in both IRPIVlanager and 
IRPAgent. This parameter can be used together with the 'cancelOperation' 
operation to cancel an on-going 'getlVIOAttributes' operation. 


baseObjectlnstance 


Input, M 


The MO where the search starts. This is a full Distinguished Name according to 
3GPPTS 32.300 [13]. 


scope 


Input, M 


This parameter defines how many levels of the containment hierarchy to search 

(i.e. apply the filter defined below). The search starts from the IVIO given by the 

baseObjectlnstance parameter. The levels of search that may be performed are: 

the base object alone (default); 

the n-th level subordinates of the base object; 

the base object and all of its subordinates down to and including the n-th level; 

the base object and all of its subordinates. 


filter 


Input, M 


This parameter defines a filter test to be applied to the scoped IVIanaged 
Object(s). If the filter is empty, all of the managed objects included by the scope 
are selected. 

The actual syntax and capabilities of the filter is Solution Set specific. However, 
each Solution Set should support a filter consisting of one or several assertions 
that may be grouped using the logical operators AND, OR and NOT. Each 
assertion is a logical expression of attribute existence, attribute value comparison 
("equal to X, less than Y" etc.) and MO Glass. 


attributeListIn 


Input, M 


This parameter identifies the attributes to be returned by this operation. In the 
current version, only the semantics "Return all attributes" shall be supported. An 
empty list means "Return all attributes". For future releases the possibility to 
specify a list of attributes is expected. 


invokeldentifierOut 


Output, M 


This parameter identifies the current invocation in both IRPManager and 
IRPAgent. This parameter can be used together with the 'cancelOperation' 
operation to cancel an on-going 'getMOAttributes' operation. 


managedObjectClass 


Output, M 


For each returned MO: The class of the MO. 


managedObjectlnstance 


Output, M 


For each returned MO: The name of the MO. This is a full Distinguished Name 
according to 3GPP TS 32.300 [13]. 


attributeListOut 


Output, M 


For each returned MO: A list of name/value pairs for the MO attributes. 


status 


Output, M 


(a) Operation succeeded, or 

(b) Operation failed because of specified or unspecified reason. 
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6.2.2 Operation getContainment (O) 

This (optional) operation is only intended for retrieval of the containment relations from the MIB. 

The output parameter 'containment' of the operation shall contain a list of all Managed Object instances in the MIB 
maintained by IRP Agent (or a subset starting from a given base object) including containment information (naming 
tree). 

The structure and format of the output parameter 'containment' are Solution Set dependent. 

Table 2: Parameters of getContainment 



Name 


Qualifier 


Description 


invokeldentifierin 


Input, C 


This parameter identifies the current invocation in both IRPManager and IRPAgent. This 
parameter can be used together with the 'cancelOperation' operation to cancel an on- 
going 'getContainment' operation. 


baseObject 
Instance 


Input, M 


The IVIO where the search starts. This is a full Distinguished Name according to 
3GPPTS 32.300 [13]. 


scope 


Input, 


This parameter gives a value N defining how many levels of the containment hierarchy 

from the baseObjectlnstance to include in the result. 

The levels of inclusion that may be performed are: 

the base object alone (default); 

the n-th level subordinates of the base object; 

the base object and all of its subordinates down to and including the n-th level; 

the base object and all of its subordinates. 


invokeldentifierOut 


Output, M 


This parameter identifies the current invocation in both IRPManager and IRPAgent. This 
parameter can be used together with the 'cancelOperation' operation to cancel an on- 
going 'getContainment' operation. 


containment 


Output, M 


A list of DN of all IVIanaged Object instances that satisfy the scope. 


status 


Output, M 


(a) Operation succeeded, or 

(b) Operation failed because of specified or unspecified reason. 



6.2.3 Operation getBasicCmlRPVersion (M) 

IRPManager wishes to find out the Basic CM IRP SS version(s) supported by IRPAgent. IRPAgent shall respond with 
a list of supported Basic CM IRP SS versions. Since the present document defines the first IRP version, 
implementation of IRPAgent in compliance to this version shall return with one version number in the list. 

Table 3: Parameters of getBasicCmiRPVersion 



Name 


Qualifier 


Description 


versionNumberList 


Output, 
M 


It indicates one or more SS version numbers supported by the IRPAgent. 
The IRP document version number (sometimes called "IRPVersion" or "version number") 
string is used to identify which specification version(s) an implementation is conformant to. 
Each string in this set is derived using a rule described in the "Generic IRP" [4]. 


status 


Output, 
M 


(a) Operation succeeded in that versionNumberList contains valid result. 

(b) Operation failed. Output parameter versionNumberList may contain invalid result. 



6.2.4 Operation cancelOperation (O) 

IRPManager invokes this operation to cancel an on-going Basic CM IRP operation it issued before. Presently the Basic 
CM IRP operations that can be cancelled by invoking 'cancelOperation' are 'getMO Attributes' and 'getContainment'. 

Table 4: Parameters of cancelOperation 



Name 


Qualifier 


Description 


invokeldentifier 


Input, IVl 


This parameter identifies an on-going Basic CM IRP operation to be cancelled. 


status 


Output, M 


(a) Operation succeeded. 

(b) Operation failed because of specified or unspecified reason. 
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6.3 



Notifications 



6.3.1 General 

Operations that IRPManager uses to manage subscription to receive notifications are specified in Notification IRP IS 
3GPP TS 32.302 [3]. Notification IRP IS [3] does not define any specific notification but instead defines information 
that is commonly found in notifications defined by other IRPs. This information is called notificationHeader. 

Thus, the commonly carried attributes in each notification are collectively called notificationHeader in the 
present document. The attribute names and their qualifiers are listed in Table 4. 

Table 4: Notification Header 



Attributes defined in 3GPP TS 32.302 [3] 


Comment 


Qualifier for use in this IS 


managedObjectClass 


(mapped to objectClass in [3]) 


M 


managedObjectlnstance 


(mapped to objectlnstance in [3]) 


M 


notificationid 







eventlime 




M 


system DN 




C 


eventlype 


(mapped to notificationlype in [3] - see 
Annex A) 


M 



The following clauses define specific notifications relevant for Basic CM IRP. 

6.3.2 Notification notifyObjectCreation (O) 

IRP Agent notifies the subscribed IRPManager that a new Managed Object has been created and that the new object 
satisfies the filter constraint expressed in IRPManager's subscribe operation (see 3GPP TS 32.302 [3]). This 
notification is based on the ob jectCreation notification type specified in ITU-T Recommendation X.721 [8] and 
ITU-T Recommendation X.730 [9] (difference compared to these specifications are indicated in the description below). 

Table 5: Parameters for notifyObjectCreation 



Name 


Qualifier 


Description 


notificationHeader 


Input, IVI 


See Table 4: Notification Header. 


correlatedNotifications 


Input, 


A set of notifications that are correlated to the subject notification. Defined in ITU-T 
Recommendation X.733 [10]. 


additionalText 


Input, 


It can contain further information on the creation of the MO. 


sourcelndicator 


Input, 


This parameter, when present, indicates the source of the operation that led to the 

generation of this notification. It can have one of the following values: 

resource operation: The notification was generated in response to an internal operation 

of the resource; 

management operation: The notification was generated in response to a management 

operation applied across the managed object boundary external to the managed object; 

unknown: It is not possible to determine the source of the operation. 


attributeList 


Input, 


The attributes (name/value pairs) of the created IVIO. 



6.3.3 Notification notifyObjectOeletion (O) 

IRP Agent notifies the subscribed IRPManager of a deleted Managed Object. The IRP Agent invokes this notification 
because the subject notification satisfies the filter constraint expressed in the IRPManager subscribe operation (see 
3GPP TS 32.302 [3]). This notification is based on the ob jectDeletion notification type specified in ITU-T 
Recommendation X.721 [8] and ITU-T Recommendation X.730 [9] (difference compared to these specifications are 
indicated in the description below). 

Note that when a Managed Object is deleted, all subordinate Managed Objects (i.e. the complete sub-tree of the MIB) 
are also deleted. Furthermore, all associations where the Managed Object participates are deleted. 
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Table 6: Parameters for notifyOb jectDeletion 



Name 


Qualifier 


Description 


notification Header 


Input, IVI 


See Table 4: Notification Header. 


correlatedNotifications 


Input, 


A set of notifications that are correlated to the subject notification. Defined in ITU-T 
Recommendation X.733 [10].. 


additionalText 


Input, 


It can contain further information on the deleted IVIO. 


sourcelndicator 


Input, 


This parameter, when present, indicates the source of the operation that led to the 

generation of this notification type. It can have one of the following values: 

resource operation: The notification was generated in response to an internal operation 

of the resource; 

management operation: The notification was generated in response to a management 

operation applied across the managed object boundary external to the managed object; 

unknown: It is not possible to determine the source of the operation. 


attributeList 


Input, 


The attributes (name/value pairs) of the deleted MO. 



6.3.4 Notification notifyAttributeValueCinange (O) 

IRP Agent notifies the subscribed IRPManager of a change of one or several attributes of a Managed Object in the 
NRM. The IRP Agent invokes this notification because the subject notification satisfies the fiher constraint expressed in 
the IRPManager subscribe operation (see 3GPP TS 32.302 [3]). This notification is based on the 
attributeValueChange notification type specified in ITU-T Recommendation X.721 [8] and ITU-T 
Recommendation X.730 [9] (difference compared to these specifications are indicated in table 7). 

Table 7: Parameters for notifyAttributeValueChange 



Name 


Qualifier 


Description 


notificationHeader 


Input, IVI 


See Table 4: Notification Header. 


correlatedNotifications 


Input, 


A set of notifications that are correlated to the subject notification. Defined in ITU-T 
Recommendation X.733 [10]. 


additionalText 


Input, 


It can contain further information on the attribute change of the IVIO. 


sourcelndicator 


Input, 


This parameter, when present, indicates the source of the operation that led to the 

generation of this notification type. It can have one of the following values: 

resource operation: The notification was generated in response to an internal operation 

of the resource; 

management operation: The notification was generated in response to a management 

operation applied across the managed object boundary external to the managed object; 

unknown: It is not possible to determine the source of the operation. 


attributeValueChange 
Definition 


Input, M 


The changed attributes (name/value pairs) of the IVIO (with both new and, optionally, old 
values). 
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Annex A (normative): 
Notification/Event Types 



Notification IRP: Information Service [3] defines an attribute called notif icationType that shall be present in all 
notifications. This document defines an attribute called eventType that shall be present in all CM notifications 
defined herein. The mapping of this eventType to the notif icationType is that they are semantically equal 
for the CM notifications. Thus, the event types described below (also the same as in Release 99) shall be mapped to the 
notif icationType of the notification header. 

This annex lists and explains Event Types used by Basic CM IRP and then lists the Event Types valid for each 
notification in this IRP. 

Encoding of eventType is Solution Set dependent. For example, the value of eventType may be encoded as an 
Object Identifier in the CMIP SS and as a numeric string in the CORBA SS. 

The following tables may be extended in the future. 

Table A.I : Event Types 



Event Types 


Explanation 


Object creation 


A notification of this type indicates that a new managed object instance has been created (as 
defined in ITU-T Recommendation X.721 [8] and ITU-T Recommendation X.730 [9]). 


Object deletion 


A notification of this type indicates that a managed object instance has been deleted (as 
defined in ITU-T Recommendation X.721 [8] and ITU-T Recommendation X.730 [9]). 


Attribute value change 


A notification of this type indicates that the value(s) of one or more attributes have changed (as 
defined in ITU-T Recommendation X.721 [8] and ITU-T Recommendation X.730 [9]). 



Table A.2: Event types applicable to each Notification 



Notification 


Event Type 


notifyObjectCreation 


Object creation 


notifyObjectDeletion 


Object deletion 


notifyAttributeValueChange 


Attribute value change 
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Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Jun 2001 


S_12 


SP-010283 


- 


- 


New document 32.602 based on 32. 1 06-5 V3. 1 .0 
Approved at TSG SA #12 and placed under Change Control 


2.0.0 


4.0.0 


Sep 2001 


S_13 


SP-010476 


001 




Replace the current parameter invokeldentifier with the two 
parameters invokeldentifierin and invokeldentifierOut in the 
operations getMoAttributes() and getContainment() 


4.0.0 


4.1.0 


Dec 2003 


S 22 


SP-030630 


004 


-- 


Correction of System Context 


4.1.0 


4.2.0 
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